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1.1 GENERAL DESCRIPTION 

The service discovery protocol (SDP) provides a means for applications to dis- 
cover which services are available and to determine the character.st.cs of 



those available services. 
1. 2 MOTIVATION 



Service Discovery in the Bluetooth environment, where the set of serves that 
are available changes dynamically based on the RF proximity of devices in 
motto ^ is qualitatively different from service discovery in traditional network- 
ed en^^^^^^ service discovery protocol defined in th.s specrf.ca- 
tionls intondedTo address the unique characteristics of the Bluetooth environ- 
ment See "Appendix A - Background Information," on page 370, for further 
information on this topic. 

1.3 REQUIREMENTS 

The following capabilities have been identified as requirements for version 1 .0 
of the Service Discovery Protocol. 

1 . SDP shall provide the ability for clients to search for needed services based 
on specific attributes of those services. 

2. SDP shall permit services to be discovered based on the class of service. 

3. SDP shall enable browsing of services without a priori knowledge of the spe- 
cific characteristics of those services. 

4 SDP shall provide the means for the discovery of new services that become 
available when devices enter RF proximity with a client dev.ce as we» as 
when a new service is made available on a device that is .n RF prox.mrty 
with the client device. 

5 SDP shall provide a mechanism for determining when a service becomes 
unavailable when devices leave RF proximity with a chent^evice as well as 
when a service is made unavailable on a device that is .n RF prox.m.ty with 
the client device. 

6. SDP shall provide for services, classes of services, and attributes of ser- 
vices to be uniquely identified. 

7. SDP shall allow a client on one device to discover a service on another 
device without consulting a third device. 

8. SDP should be suitable for use on devices of limited complexity. 

9 SDP shall provide a mechanism to incrementally discover information about 
£b i levees provided by a device. This is intended to minimize the quantity 
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of data that must be exchanged in order to determine that a particular ser- 
vice is not needed by a client. 
10 SDP should support the caching of service discovery information by inter- 
mediary agents to improve the speed or efficiency of the discovery process. 

11. SDP should be transport independent. 

12.SDP shall function while using L2CAP as its transport protocol. 

1 3. SDP shall permit the discovery and use of services that provide access to 
other service discovery protocols. 

1 4. SDP shall support the creation and definition of new services without requir- 
ing registration with a central authority. 

1 .4 NON-REQUIREMENTS AND DEFERRED REQUIREMENTS 

The Bluetooth SIG recognizes that the following capabilities are related to ser- 
vice discovery. These items are not addressed in SDP version 1 .0. However, 
some may be addressed in future revisions of the specification. 

1 . SDP 1 .0 does not provide access to services. It only provides access to 
information about services. 

2. SDP 1 .0 does not provide brokering of services. 

3. SDP 1.0 does not provide for negotiation of service parameters. 

4. SDP 1.0 does not provide for billing of service use. 

5. SDP 1 .0 does not provide the means for a client to control or change the 
operation of a service. 

6. SDP 1 .0 does not provide an event notification when services, or information 
about sen/ices, become unavailable. 

7 SDP 1.0 does not provide an event notification when attributes of sen/ices 
are modified. 

8. This specification does not define an application programming interface for 
SDP. 

9. SDP 1 .0 does not provide support for service agent functions such as ser- 
vice aggregation or service registration. 
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1.5 CONVENTIONS 

1.5.1 Bit And Byte Ordering Conventions 

When multiple bit fields are contained in a single byte and represented in a 
drawing in this specification, the more significant (high-order) bits are shown 
toward the left and less significant (low-order) bits toward the right. 

Multiple-byte fields are drawn with the more significant bytes toward the left 
and the less significant bytes toward the right. Multiple-byte fields are trans- 
ferred in network byte order. See Section 4.1 Transfer Byte Order on page 344. 
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2.1 SDP CLIENT-SERVER INTERACTION 



Client 
Application 



L 



Server 
Application 



SDP 
Client 



SDP requests 



SDP responses 



SDP 
Server 



Figure 2.1: 

The service discovery mechanism provides the means for client applications to 
discover the existence of services provided by server applications as well as 
the attributes of those services. The attributes of a service include the type or 
class of service offered and the mechanism or protocol information needed to 
utilize the service. 

As far as the Service Discovery Protocol (SDP) is concerned, the configuration 
shown in Figure 1 may be simplified to that shown in Figure 2. 




Figure 2.2: 
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SDP involves communication between an SDP server and an SDF> client. The 
server maintains a list of service records that describe the characteristics of 
"^associated with the server. Each service record contains "nformation 
about a single service. A client may retrieve information from a service record 
maintained by the SDP server by issuing an SDP request. 

If the client or an application associated with the client, decides to use a ser- 
vice? it must open a separate connection to the service provider in order to ut - 
She service. SDP provides a mechanism for discovering services and the.r 
Sto3iT(lSdlng associated service access protocols), but it does not pro- 

^rvices (such as de.ivenng the serv,ce 



access protocols). 

There is a maximum of one SDP server per Bluetooth device. (If a Bluetooth 
Jev^e let ?oTas a client, it needs no SDP server.) A single Bluetooth dev.ee 
maTfunSion both as an s6p server and as an SDP client If multip to applica- 
tTons on a device provide services, an SDP server may act on behaM f of those 
service providers to handle requests for information about the services that 
they provide. 

Similarly, multiple client applications may utilize an SDP client to query servers 
on behalf of the client applications. 

The set of SDP servers that are available to an SDP client can change dynam- 
icaHy based on the RF proximity of the servers to the client. When a server 
becomes available, a potential client must be notified by a means other than 
SDpTo toaUhe client can use SDP to query the server 
Marly, when a server leaves proximity or becomes unavailable for any reason 
here \s no explicit notification via the service discovery protocol. However, the 
client may use SDP to poll the server and may infer that the server ,s not avail- 
able if it no longer responds to requests. 

Additional information regarding application interaction with SDP is contained 
in the Bluetooth Service Discovery Profile document. 
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2.2 SERVICE RECORD 

A service is any entity that can provide information, perform an action, or con- 
trol a resource on behalf of another entity. A service may be implemented as 
software, hardware, or a combination of hardware and software. 

All of the information about a service that is maintained by an SDP server is 
contained within a single service record. The service record consists entirely of 
a list of service attributes. 



Service Record 
Service Attribute 1 
Service Attribute 2 
Service Attribute 3 



Service Attribute N 



Figure 2.3: Service Record 

A service record handle is a 32-bit number that uniquely identifies each service 
record within an SDP server. It is important to note that, in general, each han- 
dle is unique only within each SDP server. If SDP server S1 and SDP server 
S2 both contain identical service records (representing the same service), the 
service record handles used to reference these identical service records are 
completely independent. The handle used to reference the service on S1 will 
be meaningless if presented to S2. 

The service discovery protocol does not provide a mechanism for notifying cli- 
ents when service records are added to or removed from an SDP server. 
While an L2CAP (Logical Link Control and Adaptation Protocol) connection is 
established to a server, a service record handle acquired from the server will 
remain valid unless the service record it represents is removed. If a service is 
removed from the server, further requests to the server (during the L2CAP con- 
nection in which the service record handle was acquired) using the service's 
(now stale) record handle will result in an error response indicating an invalid 
service record handle. An SDP server must ensure that no service record han- 
dle values are re-used while an L2CAP connection remains established. Note 
that service record handles are known to remain valid across successive 
L2CAP connections while the ServiceDatabaseState attribute value remains 
unchanged. See the ServiceRecordState and ServiceDatabaseState attributes 
in Section 5 Service Attribute Definitions on page 358. 

There is one service record handle whose meaning is consistent across all 
SDP servers. This service record handle has the value 0x00000000 and is a 
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handle to the service record that represents the SDP server itself. This service 
record contains attributes for the SDP server and the protocol it supports. For 
example one of its attributes is the list of SDP protocol versions supported by 
the server. Service record handle values 0x00000001 -OxOOOOFFFF are 
reserved. 
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Each service attribute describes a single characteristic of a service. Some 
examples of service attributes are: 



ServiceClasslDList 



Identifies the type of service represented by a service record. > 
In other words, the list of classes of which the service is an ; 



•V t , instance 



ServicelD 



Prbtocoip^criptorLjst 



Uniquely identifies a specific instance of a service 



p^Ustp ~ ^Specifies t h^rot^>l st*K$(s) ma |p® ° S *\f Uti, |^l 



ProviderName 



The textual name of the individual or organization that pro- 
vides a service 




ServiceName 



^e^peD^^nption ■ 



A text string containing a human-readable name for the ser- 
vice 

PHI 



See Section 5.1 Universal Attribute Definitions on page 358, for attribute defini- 
tions that are common to all service records. Service providers can also define 
their own service attributes. 

A service attribute consists of two components: an attribute ID and an attribute 
value. 



Service Attribute 



Attribute ID 



Attribute Value 



Figure 2,4: Service Attribute 
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2.4 ATTRIBUTE ID 

An attribute ID is a 16-bit unsigned integer that distinguishes each service 
attribute from other service attributes within a service record. The attribute ID 
also identifies the semantics of the associated attribute value. 

A service class definition specifies each of the attribute IDs for a service class 
and assigns a meaning to the attribute value associated with each attribute ID. 

For example, assume that service class C specifies that the attribute value 
associated with attribute ID 12345 is a text string containing the date the ser- 
vice was created. Assume further that service A is an instance of service class 
C If service A's service record contains a service attribute with an attribute ID 
of 12345 the attribute value must be a text string containing the date that ser- 
vice A was created. However, services that are not instances of service class C 
may assign a different meaning to attribute ID 12345. 

All services belonging to a given service class assign the same meaning to 
each particular attribute ID. See Section 2.6 Service Class on page 336. 

In the Service Discovery Protocol, an attribute ID is often represented as a data 
element. See Section 3 Data Representation on page 341. 



Type 


Size index 








1 








1 


Attribute ID 


I 


< — 5- 


— H-3-N 


16 


► 



Figure 2.5: 

2.5 ATTRIBUTE VALUE 

The attribute value is a variable length field whose meaning is determined by 
the attribute ID associated with it and by the service class of the service record 
in which the attribute is contained. In the Service Discovery Protocol, an 
attribute value is represented as a data element. (See Section 3 Data Repre- 
sentation on page 341 .) Generally, any type of data element is permitted as an 
attribute value, subject to the constraints specified in the service class defini- 
tion that assigns an attribute ID to the attribute and assigns a meaning to the 
attribute value. See Section 5 Service Attribute Definitions on page 358, for 
attribute value examples. 
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2.6 SERVICE CLASS 

Each service is an instance of a service class. The service class definition pro- 
vides the definitions of all attributes contained in service records that represent 
instances of that class. Each attribute definition specifies the numeric value of 
the attribute ID, the intended use of the attribute value, and the format of the 
attribute value. A service record contains attributes that are specific to a ser- 
vice class as well as universal attributes that are common to all services. 

Each service class is also assigned a unique identifier. This service class iden- 
tifier is contained in the attribute value for the ServiceClasslDList attribute, and 
is represented as a UUID (see Section 2.7.1 UUID on page 337). Since the for- 
mat and meanings of many attributes in a service record are dependent on the 
service class of the service record, the ServiceClasslDList attribute is very 
important. Its value should be examined or verified before any class-specific 
attributes are used. Since all of the attributes in a service record must conform 
to all of the service's classes, the service class identifiers contained in the Ser- 
viceClasslDList attribute are related. Typically, each service class is a subclass 
of another class whose identifier is contained in the list. A service subclass def- 
inition differs from its superclass in that the subclass contains additional 
attribute definitions that are specific to the subclass. The service class identifi- 
ers in the ServiceClasslDList attribute are listed in order from the most specific 
class to the most general class. 

When a new service class is defined that is a subclass of an existing service 
class, the new service class retains all of the attributes defined in its super- 
class'. Additional attributes will be defined that are specific to the new service 
class. In other words, the mechanism for adding new attributes to some of the 
instances of an existing service class is to create a new service class that is a 
subclass of the existing sen/ice class. 

2.6.1 A Printer Service Class Example 

A color postscript printer with duplex capability might conform to 4 Service- 
Class definitions and have a ServiceClasslDList with UUIDs (See Section 2.7.1 
UUID on page 337.) representing the following ServiceClasses: 

DuplexColorPostscriptPrinterServiceClassID, 
ColorPostscriptPrinterServiceClassID, 
PostscriptPrinterServiceClassID, 
PrinterServiceClassID 

Note that this example is only illustrative. This may not be a practical printer 
class hierarchy. 
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2.7 SEARCHING FOR SERVICES 

Once an SDP client has a service record handle, it may easily request the val- 
ues of specific attributes, but how does a client initially acquire a service record 
handle for the desired service records? The Service Search transaction allows 
a client to retrieve the service record handles for particular service records 
based on the values of attributes contained within those service records. 
The capability search for service records based on the values of arbitrary 
attributes is not provided. Rather, the capability is provided to search only for 
attributes whose values are Universally Unique Identifiers 1 (UUIDs). Important 
attributes of services that can be used to search for a service are represented 
as UUIDs. 

2.7.1 UUID 

A UUID is a universally unique identifier that is guaranteed to be unique across 
all space and all time. UUIDs can be independently created in a distributed 
fashion. No central registry of assigned UUIDs is required. A UUID is a 128-bit 
value. 

To reduce the burden of storing and transferring 128-bit UUID values, a range 
of UUID values has been pre-allocated for assignment to often-used, regis- 
tered purposes. The first UUID in this pre-allocated range is known as the 
Bluetooth Base UUID and has the value 00000000-0000-1000-7007- 

00805F9B34FB, from the Bluetooth Assigned Numbers document. UUID val- 
ues in the pre-allocated range have aliases that are represented as 16-bit or 
32-bit values. These aliases are often called 16-bit and 32-brt UUIDs, but it is 
important to note that each actually represents a 128-bit UUID value. 
The full 128-bit value of a 16-bit or 32-bit UUID may be computed by a simple 
arithmetic operation. 

128_bit_value = 16_biO/alue * 2 96 + Bluetooth_Base_UUID 
I28_bit_value = 32_bit_value * 2 96 + Bluetooth_Base_UUID 

A 16-bit UUID may be converted to 32-bit UUID format by zero-extending the 
16-bit value to 32-bits. An equivalent method is to add the 16-bit UUID value to 
a zero-valued 32-bit UUID. 

Note that two 16-bit UUIDs may be compared directly, as may two 32-bit 
UUIDs or two 128-bit UUIDs. If two UUIDs of differing sizes are to be com- 
pared, the shorter UUID must be converted to the longer UUID format before 
comparison. 



1 The format of UUIDs is defined by the International Organization for Standardization ii 
IEC 11578:1996. "Information technology - Open Systems Interconnection - Remote I 
dure Call (RPC)" 
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2.7.2 Service Search Patterns 

A service search pattern is a list of UUIDs used to locate matching service 
records. A service search pattern is said to match a service record if each and 
every UUID in the service search pattern is contained within any of the service 
record's attribute values. The UUIDs need not be contained within any specific 
attributes or in any particular order within the service record. The service 
search pattern matches if the UUIDs it contains constitute a subset of the 
UUIDs in the service record's attribute values. The only time a service search 
pattern does not match a service record is if the service search pattern con- 
tains at least one UUID that is not contained within the service record's 
attribute values. Note also that a valid service search pattern must contain at 
least one UUID. 

2.8 BROWSING FOR SERVICES 

Normally, a client searches for services based on some desired characteris- 
tics) (represented by a UUID) of the services. However, there are times when 
it is desirable to discover which types of services are described by an SDP 
server's service records without any a priori information about the services. 
This process of looking for any offered services is termed browsing. In SDP, the 
mechanism for browsing for services is based on an attribute shared by all ser- 
vice classes. This attribute is called the BrowseGroupList attribute. The value 
of this attribute contains a list of UUIDs. Each UUID represents a browse group 
with which a service may be associated for the purpose of browsing. 

When a client desires to browse an SDP server's services, it creates a service 
search pattern containing the UUID that represents the root browse group. All 
services that may be browsed at the top level are made members of the root 
browse group by having the root browse group's UUID as a value within the 
BrowseGroupList attribute. 

Normally, if an SDP server has relatively few services, all of its services will be 
placed in the root browse group. However, the services offered by an SDP 
server may be organized in a browse group hierarchy, by defining additional 
browse groups below the root browse group. Each of these additional browse 
groups is described by a service record with a service class of 
BrowseGroupDescriptor. 

A browse group descriptor service record defines a new browse group by 
means of its Group ID attribute. In order for a service contained in one of these 
newly defined browse groups to be browseable, the browse group descriptor 
sen/ice record that defines the new browse group must in turn be browseable. 
The hierarchy of browseable services that is provided by the use of browse 
group descriptor service records allows the services contained in an SDP 
server to be incrementally browsed and is particularly useful when the SDP 
server contains many sen/ice records. 
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2.8.1 Example Service Browsing Hierarchy 

Here is a f ictitious service browsing hierarchy that may illuminate the manner in 
which browse group descriptors are used. Browse group descriptor service 
records are identified with (G); other service records with (S). 



Public Browse Root 



Entertainment (G) 



News (G) 



X 



Games (G) 



Movies (G) 



Starcraft (S) ] \ ABug's Life(S) 



X 



Reference (G) 
1 



Dictionary Z (S) 



EncydopediaX (S) 



| New York Times (S) | | Local Newspaper (S) { \ London Times (S) ( 



Figure 2.6: 

This table shows the services records and service attributes necessary to 
implement the browse hierarchy. 




Table 2.1: 
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A Bug's Life 


Movie Class ID 


BrowseGroupList \ % 


MovielD 


Dictionary Z 


Dictionary Class ID 


BrowseGroupList 


ReferencelD 


Encyclopedia X 


Encyclopedia Class ID 


BrowseGroupList 


ReferencelD 


New York Times 


Newspaper ID 


BrowseGroupList 


NewspaperlD 


London Times :lv 


•Newspaper ID k & ■ 


BrowseGroupList ' 


^Newspaperip -J.^ 


Local Newspaper 


Newspaper ID 


BrowseGroupList 


NewspaperlD 



Table 2.1: 
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Attribute values can contain information of various types with arbitrary com- 
plexity; thus enabling an attribute list to be generally useful across a wide vari- 
ety of service classes and environments. 

SDP defines a simple mechanism to describe the data contained within an 
attribute value. The primitive construct used is the data element. 

3.1 DATA ELEMENT 

A data element is a typed data representation. It consists of two fields: a 
header field and a data field. The header field, in turn, is composed of two 
parts: a type descriptor and a size descriptor. The data is a sequence of bytes 
whose length is specified in the size descriptor (described in Section 3 3 Data 
Element Size Descriptor on page 342) and whose meaning is (partially) speci- 
fied by the type descriptor. 

3.2 DATA ELEMENT TYPE DESCRIPTOR 

A data element type is represented as a 5-bit type descriptor. The type descrip- 
tor is contained in the most significant (high-order) 5 bits of the first byte of the 
data element header. The following types have been defined. 





6 




8 



9-31 ~~W: 



0,1.2.3.4 



5. 6.7 



s|5. 7*t|;-' 



5. 6.7 



Signed twos-complement integer 



Data element sequence, a data element whose data field 
is a sequence of data elements 



4 liquet of^^ 



£rnemis»^s»ted^ 



URL, a uniform resource locator 



■Mi 



Table 3.1: 
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3.3 DATA ELEMENT SIZE DESCRIPTOR 

The data element size descriptor is represented as a 3-bit size index followed 
by 0 8 16 or 32 bits. The size index is contained in the least significant (low- 
order) 3 bits of the first byte of the data element header. The size index is 
encoded as follows. 



Index i 



Additional 

lbife-^b II- - 



Data Size 



f 
.3? 



1 byte. Exception: if the data element type is nil, the data size is 0 
bytes. 

— w^^w— 




The data size is contained in the additional 16 bits, which are 
interpreted as an unsigned integer. 




Table 3.2: 
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Nil is represented as: 

Type Size Index 

\. i 

< — 5 — N-3-* 

A 16-bit signed integer is represented as: 
Type Size Index 



4 5 H-3-M- 



1 6-bit dat a value 
16 



he 3 character ASCII string "Hat" is represented as: 
Tvoe Size Index Size 

\l L 



I * 1 5 i 3 " 



*H' 



-3-+*- 



-8- 



-M- 



-24- 



Figure3.1: 
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4 PROTOCOL D ESCRIPTION 

SDP is a simple protocol with minimal requirements on the underlying trans- 
port. It can function over a reliable packet transport (or even unreliable, if the 
client implements timeouts and repeats requests as necessary). 

SDP uses a request/response model where each transaction consists of one 
request protocol data unit (PDU) and one response PDU. However, the 
requests may potentially be pipelined and responses may potentially be 
returned out of order. 

In the specific case where SDP utilises the Bluetooth L2CAP transport proto- 
col multiple SDP PDUs may be sent in a single L2CAP packet, but only one 
L2CAP packet per connection to a given SDP server may be outstanding at a 
given instant. Limiting SDP to sending one unacknowledged packet provides a 
simple form of flow control. 

The protocol examples found in Appendix B - Example SDP Transactions, 
may be helpful in understanding the protocol transactions. 

4.1 TRANSFER BYTE ORDER 

The service discovery protocol transfers multiple-byte fields in standard net- 
work byte order (Big Endian), with more significant (high-order) bytes being 
transferred before less-significant (low-order) bytes. 

4.2 PROTOCOL DATA UNIT FORMAT 

Every SDP PDU consists of a PDU header followed by PDU-specific parame- 
ters The header contains three fields: a PDU ID, a Transaction ID, and a 
ParameterLength. Each of these header fields is described here. Parameters 
may include a continuation state parameter, described below; PDU-specific 
parameters for each PDU type are described later in separate PDU descrip- 
tions. 



PDU Format: 




Header: 


| PDU ID | Transaction ID ParameterLength | 




4-1 byte-* 2 bytes m 2 bytes ► 


Parameters: 


| Parameter 1 | Parameter 2 -| Parameter N 




4 ParameterLength bytes > 



Figure 4. 1: 
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Size: 1 Byte 



r us- 
Value.. 


Parameter Description* „ * 


N 


The PDU ID field identifies the type ot ruu. i.e. us> meaning onu 
specific parameters. 


;ox0~o f :. . 


iReservede: t. " £ 'fly :% t| ,jr I, • r 


; y.T ^ - : ^ f V ■ 

0x01 






SDP ErrorResponse ^ 


0x03 


SDP_ServiceSearchResponse 






0x05 


SDP ServiceAttributeResponse 






0x07 


^DP^^n/iceS^ ' ■^if^Jfe 







N 


The TransactionID field uniquely identifies request PDUs and is used to 
match response PDUs to request PDUs. The SDP client can choose 
arS value forTrequesf s TransactionID provided that it is different from 
all outstanding requests. The TransactionID value in response PDUs .s 
required to be the same as the request that is being responded to. 
Range: 0x0000 - OxFFFF 


ParameterLentf 


Size: 2 Bytes 






N 


The ParameterLength field specifies the length (in bytes) oi an parame- 
ters contained in the PDU. 
Range: 0x0000 - OxFFFF 
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4.3 PARTIAL RESPONSES AND CONTINUATION STATE 

Some SDP requests may require responses that are larger than can fit in a sin- 
gle response PDU. In this case, the SDP server will generate a partial 
response along with a continuation state parameter. The continuation state 
parameter can be supplied by the client in a subsequent request to retneve the 
next portion of the complete response. The continuation state parameter is a 
variable length field whose first byte contains the number of additional bytes of 
continuation information in the field. The format of the continuation information 
is not standardized among SDP servers. Each continuation state parameter is 
meaningful only to the SDP server that generated it. 



InfoLength 



Continuation Information 



-1 byte — m InfoLength bytes- 



Figure 4.2: Continuation State Format 

After a client receives a partial response and the accompanying continuation 
state parameter, it can re-issue the original request (with a new transaction ID) 
and include the continuation state in the new request indicating to the server 
that the remainder of the original response is desired. The maximum allowable 
value of the InfoLength field is 16 (0x10). 

Note that an SDP server can split a response at any arbitrary boundary when it 
generates a partial response. The SDP server may select the boundary based 
on the contents of the reply, but is not required to do so. 

4.4 ERROR HANDLING 

Each transaction consists of a request and a response PDU. Generally, each 
type of request PDU has a corresponding type of response PDU. However, if 
the server determines that a request is improperly formatted or for any reason 
the server cannot respond with the appropriate PDU type, it will respond with 
an SDP_ErrorResponse PDU. 




Figure 4.3: 
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4.4.1 SDP_ErrorResponse PDU 



Bluetooth. 



PDU Type 


PDU ID 


Parameters . i 


SDP_ErrorResponse 


0x01 


ErrorCode, 
Errorlnfo 



Description: 

The SDP server generates this PDU type in response to an improperly format- 
ted request PDU or when the SDP server, for whatever reason, cannot gener- 
ate an appropriate response PDU. 



PDU Parameters: 

ErrorCode: 



Size: 2 Bytes 



\Value 



mmm 



.f^met^r^^pti^;,. 



N 



0x0005 
0x0007-0xFFFF 




The ErrorCode identifies the reason that an SDP.ErrorResponse PDU 
was generated. 




Invalid Continuation State 



Reserved 



S/ze: A/ Byf es 















Error-specific 


Errorlnfo is an ErrorCode-specific parameter. Its interpretation oepenos 
on the ErrorCode parameter. The currently defined ErrorCode values do 
not specify the format of an Errorlnfo field. 



Protocol Description 



29 November 1999 



347 



BNSDOCID: <XP_ 



BLUETOOTH SPECIFICATION Version 1.0 B 



page 348 of 1082 



Service Discovery Protocol 

4.5 SERV1CESEARCH TRANSACTION 



Bluetooth. 



Client 



SDP_ServiceSearchReque 



SDP_ServiceSearchRespon 



Server 



Figure 4.4: 

4.5.1 SDP_ServiceSearchRequest PDU 















SDP_ServiceSearchRequest 


0x02 


ServiceSearchPattern, 

MaximumServiceRecordCount, 

ContinuationState 



Description: 

The SDP client generates an SDP_ServiceSearch Request to locate service 
records that match the service search pattern given as the first parameter of 
the PDU Upon receipt of this request, the SDP server will examine its service 
record data base and return an SDP_ServiceSearchResponse containing the 
service record handles of service records that match the given service search 
pattern. 

Note that no mechanism is provided to request information for all service 
records However, see Section 2.8 Browsing for Services on page 338 for a 
description of a mechanism that permits browsing for non-specific services 
without a priori knowledge of the services. 

PDU Parameters: 





The Se^wiear^attem is a data element sequence where each ele- 


Data Element 
Sequence 


ment in the sequence is a UUID. The sequence must contain at least 
one UUID. The maximum number of UUIDs in the sequence is 12*. The 
list of UUIDs constitutes a sendee search pattern. 



The value ot 12 nas oeen seieciea as> <* wh.hium..^ ^"~ w " »™ — ■ . ~ 

search and the size of a search request PDU. It is not expected that more than 12 
UUIDs will be useful in a service search pattern. 
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Value : 


Parameter Description ^ v ?- * ' 


N 


MaximumServiceRecordCount is a 16-bit count specifying the maximum 
number of service record handles to be returned in the response(s) to 
this request. The SDP server should not return more handles than this 
value specifies. If more than N service records match the request, the 
SDP server determines which matching service record handles to return 
in the response(s). 

Range: 0x0001 -OxFFFF j 







Continuation 
State 


ContinuationState consists of an 8-bit count, N, of the number of bytes 
of continuation state information, followed by the N bytes of continua- 
tion state information that were returned in a previous response from 
the server. N is required to be less than or equal to 16. If no continua- 
tion state is to be provided in the request, N is set to 0. 



4.5.2 SDP_ServiceSearchResponse PDU 





Illll 




SDP_ServiceSearchResponse 


0x03 


TotalServiceRecordCount, 
CurrentServiceRecordCount, 
ServiceRecordHandleUst, 
ContinuationState 



Description: 

The SDP server generates an SDP.ServiceSearchResponse upon receipt of a 
valid SDP_ServiceSearchRequest. The response contains a list of service 
record handles for service records that match the service search pattern given 
in the request. Note that if a partial response is generated, it must contain an 
integral number of complete service record handles; a service record handle 
value may not be split across multiple PDUs. 
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PDU Parameters: 

TotalServiceRecordCount: 



Bluetooth. 



Size: 2 Bytes 



Value 




Parameter Description 


N 




The TotalServiceRecordCount is an integer containing the number of 
service records that match the requested service search pattern. If no 
service records match the requested service search pattern, this param- 
eter is set to 0. N should never be larger than the MaximumServiceRe- 
cordCount value specified in the SDP_ServiceSearchRequest. When 
multiple partial responses are used, each partial response contains the 
same value for TotalServiceRecordCount. 
Range: OxOOOO-OxFFFF 


CurrentServiceF 


lecordCount: Size: 2 Bytes 


f IP t 
■ Value 1 




Parameter Efescriptlon^ f|§f |Jp |l fill i llP A 


N 




The CurrentServiceRecordCount is an integer indicating the number of 
service record handles that are contained in the next parameter. If no 
service records match the requested service search pattern, this param- 
eter is set to 0. N should never be larger than the TotalServiceRecord- 
Count value specified in the current response. 
Range: OxOOOO-OxFFFF 



ServiceRecordHandleList 



Size: (CurrentServiceRecordCount*4) Bytes 





^ Parameter Description: £ 






Ustof 

32-bit handles 


The ServiceRecordHandleUst contains a list of service record handles. 
The number of handles in the list is given in the CurrentServiceRecord- 
Count parameter. Each of the handles in the list refers to a service 
record that matches the requested service search pattern. Note that this 
list of service record handles does not have the format of a data ele- 
ment. It contains no header fields, only the 32-bit service record han- 
dles. 



ContinuationState. 



Size: 1 to 17 Bytes 



value ;vv%p-~- 


- parameter ^escr.Rjion;^ ^ tiffi ' -11 


f: #1 

' • - H r -fit ^ • 


Continuation 
State 


ContinuationState consists of an 8-bit count, N, of the number of bytes 
of continuation state information, followed by the N bytes of continua- 
tion information. If the current response is complete, this parameter 
consists of a single byte with the value 0. If a partial response is con- 
tained in the PDU, the ContinuationState parameter may be supplied in 
a subsequent request to retrieve the remainder of the response. 
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4.6 SERVICEATTRIBUTE TRANSACTION 



Bluetooth. 



SDP_ServiceAttributeRequest 




Server 



Figure 4.5: 

4.6.1 SDP_ServiceAttributeRequest PDU 









SDP__ServiceAttributeRequest 


0x04 


ServiceRecordHandle, 
MaximumAttributeByteCount, 
AttributelDUst, 
ContinuationState 



Description: 

The SDP client generates an SDP.ServiceAttributeRequest to retrieve speci- 
fied attribute values from a specific service record. The service record handle 
of the desired service record and a list of desired attribute IDs to be retneved 
from that service record are supplied as parameters. 



Command Parameters: 



Size: 4 Bytes 





The ServiceRecordHandle pai^ete^pecifies the service i record to™ 


32-bit handle 


which attribute values are to be retrieved. The handle is obtained via a 
previous SDP_ServiceSearch transaction. 


MaximumAttribu 


tcRvteCount: Size: 2 Bytes 






N 


MaximumAttributeByteCount specifies the maximum number ofbytesof 
attribute data to be returned in the response(s) to this request. The SDP 
server should not return more than N bytes of attribute data in the 
response(s). If the requested attributes require more than N bytes, the 
SDP server determines how to truncate the list. 
Range: 0x0007-OxFFFF 
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Size: Varies 



value : 


Parameter Description; '.<. V-"\.< 


Data Element 
Sequence 


The AttributelDList is a data element sequence where each element in 
the list is either an attribute ID or a range of attribute IDs. Each attribute 
ID is encoded as a 16-bit unsigned integer data element. Each attnbute 
ID range is encoded as a 32-bit unsigned integer data element, where 
the high order 16 bits are interpreted as the beginning attnbute ID of the 
range and the low order 16 bits are interpreted as the ending attnbute ID 
of the range. The attribute IDs contained in the AttributelDList must be 
listed in ascending order without duplication of any attnbute ID values. 
Note that all attributes may be requested by specifying a range of 
OxOOOO-OxFFFF. 







Continuation 
State 


ContinuationState consists of an 8-bit count, N, of the numoer 01 bytes 
of continuation state information, followed by the N bytes of continua- 
tion state information that were returned in a previous response from 
the server. N is required to be less than or equal to 16. If no continua- 
tion state is to be provided in the request, N is set to 0. 



4.6.2 SDP_ServiceAttributeResponse PDU 









SDP_ServiceAttributeResponse 


0x05 


AttributeUstByteCount, 

AttributeList, 

ContinuationState 



Description: 

The SDP server generates an SDP.ServiceAttributeResponse upon receipt of 
a valid SDP ServiceAttributeRequest. The response contains a list ot 
attributes (both attribute ID and attribute value) from the requested service 
record. 

PDU Parameters: 





£p a ?ameter Description W % 4 ~M 




N 


The AttributeUstByteCount contains a count of the number ot Dytes in 
the AttributeList parameter. N must never be larger than the Maximu- 
mAttributeByteCount value specified in the 
SDP_ServiceAttributeRequest. 

Range: Ox0002-OxFFFF 
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Value ? 


Parameter Description *3p'-~K 


Data Element 
Sequence 


The AttributeUst is a data element sequence containing attribute IDs 
and attribute values. The first element in the sequence contains the 
attribute ID of the first attribute to be returned. The second element in 
the sequence contains the corresponding attribute value. Successive 
pairs of elements in the list contain additional attribute ID and value 
pairs. Only attributes that have non-null values within the service record 
and whose attribute IDs were specified in the 

SDP ServiceAttributeRequest are contained in the AttnbuteUst Neither 
an attribute ID nor an attribute value is placed in the AttributeUst for 
attributes in the service record that have no value. The attnbutes are 
listed in ascending order of attribute ID value. 



Value ' 


ContinuationState consists o^n^it oount, N, of the number of lytes 


Continuation 
State 


of continuation state information, followed by the N bytes of continua- 
tion information. If the current response is complete, this parameter 
consists of a single byte with the value 0. If a partial response is given, 
the ContinuationState parameter may be supplied in a subsequent 
request to retrieve the remainder of the response. 



BNSDOCID: 
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4.7 SERVICESEARCHATTRIBUTE TRANSACTION 





SDP_ServiceSearchAttributeRequest 




Client 




Server 


SDP ServiceSearchAttributeResponse 
< = — 1 





Figure 4.6: 

4.7.1 SDP_ServiceSearchAtlributeRequest PDU 





pduiid:: 






SDP^ServiceSearchAttributeRequest 


0x06 


ServiceSearchPattern, 
MaximtimAttributeByteCount, 
AttributelDList, 
ContinuationState 



Description: 

The SDP_ServiceSearchAttributeRequest transaction combines the capabili- 
ties of the SDP_ServiceSearchRequest and the SDP_ServiceAttributeRequest 
into a single request. As parameters, it contains both a service search pattern 
and a list of attributes to be retrieved from service records that match the ser- 
vice search pattern. The SDP_ServiceSearchAttributeRequest and its 
response are more complex and may require more bytes than separate 
SDP_ServiceSearch and SDP_ServiceAttribute transactions. However, using 
SDP_ServiceSearchAttributeRequest may reduce the total number of SDP 
transactions, particularly when retrieving multiple service records. 

Note that the service record handle for each service record is contained in the 
ServiceRecordHandle attribute of that service and may be requested along 
with other attributes. 
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PDU Parameters: 



Size: Varies 



Value 


Parameter Description . : V : f 


Data Element 
Sequence 


The ServiceSearchPattern is a data element sequence where each ele- 
ment in the sequence is a UUID. The sequence must contain at least 
one UUID. The maximum number of UUIDs in the sequence is 12 . The 
list of UUIDs constitutes a service search pattern. 



Thp va ue of 12 has oeen seiecieu <is> uuihkiwh»^ — ■ ^_ -r . 

search the size of a search request PDU. It is not expected that more than 12 
UUIDs will be useful in a service search pattern. 



Size: 2 Bytes 











MaximumAttributeByteCount specifies the maximum number ot o^es or 
attribute data to be returned in the response(s) to this request. The SDP 
server should not return more than N bytes of attribute data in the 
response(s). If the requested attributes require more than N bytes, the 
SDP server determines how to truncate the list. 
Range: Ox0009-OxFFFF 



Size: Varies 




Data Element 
Sequence 



The AttributelDList is a data element sequence where each element in 
the list is either an attribute ID or a range of attribute IDs. Each attnbute 
ID is encoded as a 16-bit unsigned integer data element. Each attribute 
ID range is encoded as a 32-bit unsigned integer data element, where 
the high order 16 bits are interpreted as the beginning attnbute ID of the 
range and the low order 1 6 bits are interpreted as the ending attribute ID 
of the range. The attribute IDs contained in the AttributelDList must be 
listed in ascending order without duplication of any attribute ID values. 
Note that all attributes may be requested by specifying a range of 
OxOOOO-OxFFFF. 



Size: 1 to 17 Bytes 



KsUIIUI lUCtUUl iuta« 




Continuation 
State 


ContinuationState consists of an 8-bit count N, of the number of bytes 
of continuation state information, followed by the N bytes of continua- 
tion state information that were returned in a previous response from 
the server. N is required to be less than or equal to 16. If no continua- 
tion state is to be provided in the request, N is set to 0. 
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4.7.2 SDP_ServiceSearchAttributeResponse PDU 



PDUTyp* 111 


PDU ID 


Parameters 


SDP_ServiceSearchAttiibuteResponse 


0x07 


AttributeUstsByteCount, 

AttributeUsts, 

ContinuationState 



Description: 

The SDP server generates an SDP_ServiceSearchAttributeResponse upon 
receipt of a valid SDP_ServiceSearchAttributeRequest. The response contains 
a list of attributes (both attribute ID and attribute value) from the service 
records that match the requested service search pattern. 



PDU Parameters: 



A ttributeListsByteCount: 



Value 


Parameter.Descnption ^ - 0 : 




N 


The AttributeUstsByteCount contains a count of the number of bytes in 
the AttributeUsts parameter. N must never be larger than the Maximu- 
mAttributeByteCount value specified in the 
SDP_ServiceSearchAttributeRequest. 

Range: 0x0002-0xFFFF 







Data Element 
Sequence 


The AttributeUsts is a data element sequence where each element in 
turn is a data element sequence representing an attribute list. Each 
attribute list contains attribute IDs and attribute values from one service 
record The first element in each attribute list contains the attribute ID of 
the first attribute to be returned for that service record. The second ele- 
ment in each attribute list contains the corresponding attribute value. 
Successive pairs of elements in each attribute list contain additional 
attribute ID and value pairs. Only attributes that have non-null values 
within the service record and whose attribute IDs were specified in the 
SDP ServiceSearchAttributeRequest are contained in the 
AttributeUsts. Neither an attribute ID nor attribute value is placed in 
AttributeUsts for attributes in the service record that have no value. 
Within each attribute list, the attributes are listed in ascending order of 
attribute ID value. 
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Valued -v . [■ 


Parameter Description , "v. 






Continuation 
State 


ContinuationState consists of an 8-bit count. N, of the number ot Dytes 
of continuation state information, followed by the N bytes of continua- 
tion information. If the current response is complete, this parameter 
consists of a single byte with the value 0. If a partial response is given, 
the ContinuationState parameter may be supplied in a subsequent 
request to retrieve the remainder of the response. 
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5 SERVICE ATTRIBUTE DEFINITIONS 



The service classes and attributes contained in this document are necessarily 
a partial list of the service classes and attributes supported by SDR Only ser- 
vice classes that directly support the SDP server are included in this document. 
Additional service classes will be defined in other documents and possibly in 
future revisions of this document. Also, it is expected that additional attributes 
will be discovered that are applicable to a broad set of services; these may be 
added to the list of Universal attributes in future revisions of this document. 

5.1 UNIVERSAL ATTRIBUTE DEFINITIONS 

Universal attributes are those service attributes whose definitions are common 
to all service records. Note that this does not mean that every service record 
must contain values for all of these service attributes. However, if a service 
record has a service attribute with an attribute ID allocated to a universal 
attribute, the attribute value must conform to the universal attribute's definition. 

Only two attributes are required to exist in every service record instance. They 
are the ServiceRecordHandle (attribute ID 0x0000) and the ServiceClasslDList 
(attribute ID 0x0001). All other service attributes are optional within a service 
record. 

5.1.1 ServiceRecordHandle Attribute 



Description: 

A service record handle is a 32-bit number that uniquely identifies each service 
record within an SDP server. It is important to note that, in general, each han- 
dle is unique only within each SDP server. If SDP server S1 and SDP server 
S2 both contain identical service records (representing the same service), the 
service record handles used to reference these identical service records are 
completely independent. The handle used to reference the service on S1 will, 
in general, be meaningless if presented to S2. 




ServiceRecordHandle 



0x0000 32-bit unsigned integer 
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Attribute Name 


Attribute ID 


Attribute Value Type 


ServiceClasslDList 


0x0001 


Data Element Sequence 



Description: 

The ServiceClasslDList attribute consists of a data element sequence in which 
each data element is a UUID representing the service classes that a given ser- 
vice record conforms to. The UUIDs are listed in order from the most specific 
class to the most general class. The ServiceClasslDList must contain at least 
one service class UUID. 



5.1.3 ServiceRecordState Attribute 



^Attriiut^Klarrie^ r 






fAttrid^^^^V^^-^l^ 


ServiceRecordState 


0x0002 


32-bit unsigned integer 



Description: 

The ServiceRecordState is a 32-bit integer that is used to facilitate caching of 
ServiceAttributes. If this attribute is contained in a service record, its value is 
quaranteed to change when any other attribute value is added to deleted from 
or changed within the service record. This permits a client to check the value of 
this single attribute. If its value has not changed since it was last checked, the 
client knows that no other attribute values within the service record have 
changed. 

5.1.4 ServicelD Attribute 









ServicelD 


0x0003 


UUID 



Description: 

The ServicelD is a UUID that universally and uniquely identifies the service 
instance described by the service record. This service attribute is particularly 
useful if the same service is described by service records in more than one 
SDP server. 
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5.1.5 ProtocolDescriptorList Attribute 



Attribute Name 


Attribute ID 


Attribute Value Type 


ProtocolDescriptorList 


0x0004 


Data Element Sequence or Data 
Element Alternative 



Description: 

The ProtocolDescriptorList attribute describes one or more protocol stacks that 
may be used to gain access to the service described by the service record. 

If the ProtocolDescriptorList describes a single stack, it takes the form of a data 
element sequence in which each element of the sequence is a protocol 
descriptor. Each protocol descriptor is, in turn, a data element sequence whose 
first element is a UUID identifying the protocol and whose successive elements 
are protocol-specific parameters. Potential protocol-specific parameters are a 
protocol version number and a connection-port number. The protocol descrip- 
tors are listed in order from the lowest layer protocol to the highest layer proto- 
col used to gain access to the service. 

If it is possible for more than one kind of protocol stack to be used to gain 
access to the service, the ProtocolDescriptorList takes the form of a data ele- 
ment alternative where each member is a data element sequence as described 
in the previous paragraph. 

Protocol Descriptors 

A protocol descriptor identifies a communications protocol and provides proto- 
col-specific parameters. A protocol descriptor is represented as a data element 
sequence. The first data element in the sequence must be the UUID that iden- 
tifies the protocol. Additional data elements optionally provide protocol-specific 
information, such as the L2CAP protocol/service multiplexer (PSM) and the 
RFCOMM server channel number (CN) shown below. 

ProtocolDescriptorList Examples 

These examples are intended to be illustrative. The parameter formats for each 
protocol are not defined within this specification. 

In the first two examples, it is assumed that a single RFCOMM instance exists 
on top of the L2CAP layer. In this case, the L2CAP protocol specific information 
(PSM) points to the single instance of RFCOMM. In the last example, two dif- 
ferent and independent RFCOMM instances are available on top of the L2CAP 
layer In this case, the L2CAP protocol specific information (PSM) points to a 
distinct identif ier that distinguishes each of the RFCOMM instances. According 
to the L2CAP specification, this identifier takes values in the range 
0x1O0O-0xFFFF. 
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IrDA-like printer 

( ( L2CAP, PSM=RFCOMM ), ( RFCOMM, CN=1 ), ( PostscriptStream ) ) 
IP Network Printing 

( ( L2CAP, PSM=RFCOMM ), ( RFCOMM, CN=2 ), ( PPP ), ( IP ), ( TCP ), 
(IPP)) 

Synchronization Protocol Descriptor Example 

( ( L2CAP, PSM=0x1001 ), ( RFCOMM, CN=1 ), ( Obex ), ( vCal ) ) 

( ( L2CAP, PSM=0x1002 ), ( RFCOMM, CN=1 ), ( Obex ), 
( otherSynchronisationApplication ) ) 

5.1 .6 BrowseGroupList Attribute 









BrowseGroupList 


0x0005 


Data Element Sequence 



Description: 

The BrowseGroupList attribute consists of a data element sequence in which 
each element is a UUID that represents a browse group to which the service 
^EEigi. The top-.eve. browse group ID. ^ Pvt *fS!S^SSa 
representing the root of the browsing hierarchy, has the value 00001002-0000- 
1000-7007-00805F9B34FB (UUID16: 0x1002) from the Bluetooth Assigned 
Numbers document. 

5.1.7 LanguageBaseAttributelDList Attribute 





^Attribute IDM;-? 




LanguageBaseAttributelDList 


0x0006 


Data Element Sequence 



Description: 

In order to support human-readable attributes for multiple natural languages in 
a single service record, a base attribute ID is assigned for each of ttw .natural 
languages used in a service record. The human-readable umversal attributes 
are then defined with an attribute ID offset from each of these base values, 
rather than with an absolute attribute ID. 

The LanguageBaseAttributelDList attribute is a list in which each member con- 
tains a language identifier, a character encoding identifier, and a base attribute 
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ID for each of the natural languages used in the service record. The Language- 
BaseAttributelDList attribute consists of a data element sequence in which 
each element is a 1 6-bit unsigned integer. The elements are grouped as triplets 
(threes). 

The first element of each triplet contains an identifier representing the natural 
language. The language is encoded according to ISO 639:1988 (E/F): "Code 
for the representation of names of languages". 

The second element of each triplet contains ah identifier that specifies a char- 
acter encoding used for the language. Values for character encoding can be 
found in lANA's database 2 , and have the values that are referred to as MIBE- 
num values. The recommended character encoding is UTF-8. 

The third element of each triplet contains an attribute ID that serves as the 
base attribute ID for the natural language in the service record. Different ser- 
vice records within a server may use different base attribute ID values for the 
same language. 

To facilitate the retrieval of human-readable universal attributes in a principal 
language, the base attribute ID value for the primary language supported by a 
service record must be 0x0100. Also, if a LanguageBaseAttributelDList 
attribute is contained in a service record, the base attribute ID value contained 
in its first element must be 0x0100. 

5.1.8 ServicelnfoTimeToLive Attribute 













ServicelnfoTimeToLive 


0x0007 


32-bit unsigned integer 



Description: 

The ServiceTimeToLive attribute is a 32-bit integer that contains the number of 
seconds for which the information in a service record is expected to remain 
valid and unchanged. This time interval is measured from the time that the 
attribute value is retrieved from the SDP server. This value does not imply a 
guarantee that the service record will remain available or unchanged. It is 
simply a hint that a client may use to determine a suitable polling interval to re- 
validate the service record contents. 



I 2. See http-7Awww.isi.edu/in-notes/iana/assignments/character-sets 
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5.1.9 ServiceAvailability Attribute 



Bluetooth. 



Attribute Name 


Attribute ID : 


Attribute Value Type / 


ServiceAvailability 


0x0008 


8-bit unsigned integer 



Description: 

The ServiceAvailability attribute is an 8-bit unsigned integer that represents the 
relative ability of the service to accept additional clients. A value of OxFF ^indi- 
cates that the service is not currently in use and is thus fully available, while a 
value of 0x00 means that the service is not accepting new clients. For services 
that support multiple simultaneous clients, intermediate values indicate the rel- 
ative availability of the service on a linear scale. 

For example, a service that can accept up to 3 clients should provide Service- 
Availability values of OxFF, OxAA, 0x55, and 0x00 when 0, 1, 2, and 3 clients^ 
respectively, are utilising the service. The value OxAA is approximately (2/3) 
OxFF and represents 2/3 availability, while the value 0x55 is approximately (1/ 
3)*0xFF and represents 1/3 availability. Note that the availability value may be 
approximated as 

( 1 - ( current_number_of_clients / maximum_number_of_clients ) ) * OxFF 

When the maximum number of clients is large, this formula must be modified to 
ensure that ServiceAvailability values of 0x00 and OxFF are reserved for their 
defined meanings of unavailability and full availability, respectively. 

Note that the maximum number of clients a service can support may vary 
according to the resources utilised by the service's current clients. 

A non-zero value for ServiceAvailability does not guarantee that the service will 
be available for use. It should be treated as a hint or an approximation of avail- 
ability status. 

5.1.10 BluetoothProfileDescriptorUst Attribute 



*^*ibme|Ntarra 

• r<w, v «fe-.v>,- .-. Sac?:?-. -? 


1 ill M ^;>j 




Afibuf ID|§f 




BluetoothProfileDescriptorUst 


0x0009 


Data Element Sequence 



Description: 

The BluetoothProfileDescriptorUst attribute consists of a data element 
sequence in which each element is a profile descriptor that contains informa- 
tion about a Bluetooth profile to which the service represented by this service 
record conforms. Each profile descriptor is a data element sequence whose 
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first element is the UUID assigned to the profile and whose second element is 
a 16-bit profile version number. 

Each version of a profile is assigned a 16-bit unsigned integer profile version 
number, which consists of two 8-bit fields. The higher-order 8 bits contain the 
major version number field and the lower-order 8 bits contain the minor version 
number field. The initial version of each profile has a major version of 1 and a 
minor version of 0. When upward compatible changes are made to the profile, 
the minor version number will be incremented. If incompatible changes are 
made to the profile, the major version number will be incremented. 

5.1.11 DocumentationURL Attribute 





AttribmelDr 


^Attribute Value ^ype;^fe- 


DocumentationURL 


OxOOOA 


URL 



Description: 

This attribute is a URL which points to documentation on the service described 
by a service record. 



5.1.12 ClientExecutableURL Attribute 



hams* $ e s ^ i a 




•Attribute>Va.ue,Type f 




ClientExecutableURL 


OxOOOB 


URL 



Description: 

This attribute contains a URL that refers to the location of an application that 
may be used to utilize the service described by the service record. Since differ- 
ent operating environments require different executable formats, a mechanism 
has been defined to allow this single attribute to be used to locate an execut- 
able that is appropriate for the client device's operating environment. In the 
attribute value URL, the first byte with the value 0x2A (ASCII character '*') is to 
be replaced by the client application with a string representing the desired 
operating environment before the URL is to be used. 
The list of standardized strings representing operating environments is con- 
tained in the Bluetooth Assigned Numbers document. 
For example, assume that the value of the ClientExecutableURL attribute is 
http7/my fake/public/Vclient.exe. On a device capable of executing SH3 Win- 
dowsCE files, this URL would be changed to http://my.fake/public/sh3- 
microsoft-wince/client.exe. On a device capable of executing Windows 98 
binaries, this URL would be changed to http://my.fake/public/i86-microsoft- 
win987client.exe. 
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Attribute Name '$?f'%& > - 


Attribute ID % 


Attribute Value Type { 


IconURL 


OxOOOC 


URL 



Description: 

This attribute contains a URL that refers to the location of 
used to represent the service described by the serv.ce record. Since different 
hardware devices require different icon formats, a mechanism hajtaen, 
defined to allow this single attribute to be used to locate an icon that a i appro- 
Dria?e for the client device. In the attribute value URL, the first byte with the 
Salul 0X2MASCH character ~) is to be replaced by the client appl.cat.or .wrth 
a string representing the desired icon format before the URL is to be used. 

The list of standardized strings representing icon formats is contained in the 
Bluetooth Assigned Numbers document. 

For example, assume that the value of the IconURL attribute Is ^m*** 
pCblic/icons/ ; . On a device that prefers 24 x 24 icons wrth 256 colors, this > URL 
would be changed to http^/my.fake/pubr^con^^xS^ng^On a device that 
prefers 1 0 x 10 monochrome icons, this URL would be changed to http7/ 
my.fake/public/icons/1 0x1 0x1 .png. 

5.1.14 ServiceName Attribute 



Attribute Name*?* 






ServiceName 


0x0000 


String 



Description: 

The ServiceName attribute is a string containing the name of the service repre- 
sented a service record. It should be brief and suitable for display with an 
S Presenting the service. The offset 0x0000 must be added to the attribute 
l^S^SSdS the LanguageBaseAttributelDList attribute) in order to 
compute the attribute ID for this attribute. 
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5.1.15 ServiceDescription Attribute 



Attribute Name 


Attribute ID Offset 


Attribute Value Type 


ServiceDescri ptlon 


0x0001 


String 



Description: 

This attribute is a string containing a brief description of the service. It should 
be less than 200 characters in length. The offset 0x0001 must be added to the 
attribute ID base (contained in the LanguageBaseAttributelDList attribute) in 
order to compute the attribute ID for this attribute. 



5.1.16 ProviderName Attribute 







Attr/ute^lu^yp,^ .J# ~J 




ProviderName 


0x0002 


String 



Description: 

This attribute is a string containing the name of the person or organization pro- 
viding the service. The offset 0x0002 must be added to the attribute ID base 
(contained in the LanguageBaseAttributelDList attribute) in order to compute 
the attribute ID for this attribute. 



5.1.17 Reserved Universal Attribute IDs 

Attribute IDs in the range of Ox0OOD-OxO1FF are reserved. 
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5 2 SERVICEDISCOVERYSERVER SERVICE CLASS 
ATTRIBUTE DEFINITIONS 

This service class describes service records that contain attributes of service 
discovery server itself. The attributes listed in this section are only valid if the 
ciprviceClasslDList attribute contains the 

I^^SSv^rverServloeClasslD. Note that all of the universe attributes 
may be included in service records of the ServiceDiscoveryServer class. 

5.2.1 ServiceRecordHandle Attribute 

Described in the universal attribute definition for ServiceRecordHandle. 
Value 

A 32-bit integer with the value 0x000000000. 

5.2.2 ServiceClasslDList Attribute 

Described in the universal attribute definition for ServiceClasslDList. 
Value 

A UUID representing the ServiceDiscoveryServerServiceClasslD. 

5.2.3 VersionNumberList Attribute 



^AtSbuie Nam/ f j.' / .AjjJ 




J^ttribuTe Value Jypdfe 


VersionNumberList 


0x0200 


Data Element Sequence 



Description: 

The VersionNumberList is a data element sequence in which each element of 
the sequence is a version number supported by the SDP server. 

A version number is a 16-bit unsigned integer consisting of two ^Ids^The 
higher-order 8 bits contain the major vers.on number .eld and the tow-order 8 
bite contain the minor version number field. The initial vers.on of SDP has a 
major version of 1 and a minor version of 0. When U ^?™E£S*T^ 
are made to the protocol, the minor vers.on number will be mcreme nted If 
incompatible changes are made to SDP, the major version number will be 
incremented This guarantees that if a client and a server support a common 
ma orTe"ston number, they can communicate if each uses only features of the 
^hSTI a minor version number that is supported by both client and 
server. 
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5.2.4 ServiceDatabaseState Attribute 




Attribute ID 



Attribute Value Type 



ServiceDatabaseState 



0x0201 



32-bit unsigned integer 



Description: 

The ServiceDatabaseState is a 32-bit integer that is used to facilitate caching 
of service records. If this attribute exists, its value is guaranteed to change 
when any of the other service records are added to or deleted from the server's 
database. If this value has not changed since the last time a client queried its 
value, the client knows that a) none of the other service records maintained by 
the SDP server have been added or deleted; and b) any service record han- 
dles acquired from the server are still valid. A client should query this 
attribute's value when a connection to the server is established, prior to using 
any service record handles acquired during a previous connection. 

Note that the ServiceDatabaseState attribute does not change when existing 
service records are modified, including the addition, removal, or modification of 
service attributes. A service record's ServiceRecordState attribute indicates 
when that service record is modified. 

5.2.5 Reserved Attribute IDs 

Attribute IDs in the range of 0x0202-0x02FF are reserved. 



368 



227929GA_I_> 



29 November 1999 



Service Attribute Definitions 



BLUETOOTH SPECIFICATION Version 1 .0 B page 369 of 1082 

Service Discovery Protocol BIlIBtOOtll. 

5.3 BROWSEGROUPDESCRIPTOR SERVICFCLASS 
ATTRIBUTE DEFINITIONS 

This service class describes the ServiceRecord provided for each Browse- 
GroupDescriptor service offered on a Bluetooth device. The attributes listed in 
this section are only valid if the ServiceClasslDList attribute contains ; he Brow- 
seGroupDescriptorServiceClasslD. Note that all of the universal attributes may 
be included in service records of the BrowseGroupDescnptor class. 

5.3.1 ServiceClasslDList Attribute 

Described in the universal attribute definition for ServiceClasslDList. 



Value 

A UUID representing the BrowseGroupDescriptorServiceClasslD. 



5.3.2 GroupID Attribute 









GroupID 


0x0200 


UUID 



Description: 

This attribute contains a UUID that can be used to locate services 
members of the browse group that this service record describes. 



5.3.3 Reserved Attribute IDs 

Attribute IDs in the range of 0x0201 -0x02FF are reserved. 
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APPENDIX A - BACKGROUND INFORMATION 



A.1. Service Discovery 

As computing continues to move to a network-centric model, finding and mak- 
ing use of services that may be available in the network becomes increasingly 
important. Services can include common ones such as printing, paging, FAX- 
ing and so on, as well as various kinds of information access such as telecon- 
ferencing, network bridges and access points, eCommerce facilities, and so on 
— most any kind of service that a server or service provider might offer. In 
addition to the need for a standard way of discovering available services, there 
are other considerations: getting access to the services (finding and obtaining 
the protocols, access methods, "drivers" and other code necessary to utilize 
the service), controlling access to the sen/ices, advertising the services, choos- 
ing among competing services, billing for services, and so on. This problem is 
widely recognized; many companies, standards bodies and consortia are 
addressing it at various levels in various ways. Service Location Protocol 
(SLP), Jini™, and Salutation™, to name just a few, all address some aspect of 
service discovery. 



A.2. Bluetooth Service Discovery 

Bluetooth Service Discovery Protocol (SDP) addresses service discovery spe- 
cifically for the Bluetooth environment. It is optimized for the highly dynamic 
nature of Bluetooth communications. SDP focuses primarily on discovering 
services available from or through Bluetooth devices. SDP does not define 
methods for accessing services; once services are discovered with SDP, they 
can be accessed in various ways, depending upon the service. This might 
include the use of other service discovery and access mechanisms such as 
those mentioned above; SDP provides a means for other protocols to be used 
along with SDP in those environments where this can be beneficial. While SDP 
can coexist with other service discovery protocols, it does not require them. In 
Bluetooth environments, services can be discovered using SDP and can be 
accessed using other protocols defined by Bluetooth. 
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APPENDIX B - EXAMPLE SDP TRANSACTIONS 

The following are simple examples of typical SDP transactions. These are 
meant to be illustrative of SDP flows. The examples do not consider: 

• Caching (in a caching system, the SDP client would make use of the 
ServiceRecordState and ServiceDatabaseState attributes); 

• Service availability (if this is of interest, the SDP client should use the 
ServiceAvailability and/or ServiceTimeToLive attributes); 

• SDP versions (the Version NumberList attribute could be used to determine 
compatible SDP versions); 

• SDP Error Responses (an SDP error response is possible for any SDP 
request that is in error); and 

• Communication connection (the examples assume that an L2CAP 
connection is established). 

The examples are meant to be illustrative of the protocol. The format used is 

ObjectName[ObjectSizeInBytes) {SubObjectDef initions] ,, but this IS not 

meant to illustrate an interface. The objectsizeinBytes is the size of the object 
in decimal. The subobjectDef initions (inside of {} characters) are compo- 
nents of the immediately enclosing object. Hexadecimal values shown as 
lower-case letters, such as for transaction IDs and service handles, are vari- 
ables (the particular value is not important for the illustration, but each such 
symbol always represents the same value). Comments are included in this 
manner: /* comment text */. 

B.1. SDP Example 1 - ServiceSearchRequest 

The first example is that of an SDP client searching for a generic printing ser- 
vice The client does not specify a particular type of printing service. In the 
example, the SDP server has two available printing services. The transaction 
illustrates: 

1 SDP client to SDP server: SDP.ServiceSearchRequest, specifying the 

" PrinterServiceClassID (represented as a DataElement with a 32-bit UUID 
value of ppp . - . ppp) as the only element of the ServiceSearchPattern. The 
PrinterServiceClassID is assumed to be a 32-bit UUID and the data element 
type for it is illustrated. The TransactionID is illustrated as tttt. 

2 SDP server to SDP client: SDP.ServiceSearchResponse, returning handles 
to two printing services, represented as qqqqqqqq for the first pnnting ser- 
vice and rrrrrrrr for the second printing service. The Transaction ID is 
the same value as supplied by the SDP client in the corresponding request 
(ttxt). 

/* Sent from SDP Client to SDP server */ 
SDP_ServiceSearchRequest tlS] { 
PDUIDtl] { 
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0x02 

} 

TransactionID [2] { 
Oxtttt 

ParameterLength [2 ] { 
0x00 OA 

ServiceSearchPattern [7] { 
DataElementSequence [71 { 
ObOOllO OblOl 0x05 
UUID[5] { 

/* PrinterServiceClassID */ 
ObOOOll ObOlO Oxpppppppp 

} 

} 

MaximumServiceRecordCount [2] { 
0x0003 

ContinuationState [1 3 { 

/* no continuation state */ 
0x00 

} 

} 



/* Sent from SDP server to SDP client 
SDP_ServiceSearchResponse [16] { 
PDUID[1] { 
0x03 

} 

TransactionID [2] { 
Oxtttt 

} 

ParameterLength [2] { 
0x0 00D 

TotalServiceRecordCount [2] { 
0x0002 

Current ServiceRecordCount [2] { 
0x0002 

ServiceRecordHandleList [8] { 
/* print service 1 handle */ 
Oxqqqqqqqq 

/* print service 2 handle */ 
Oxrrrrrrrr 

ContinuationState [1] { 

/* no continuation state */ 
0x00 

} 

} 
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B.2. SDP Example 2 - ServiceAttributeTransaction 

The second example continues the first example. In Example 1 , the SDP client 
obtained handles to two printing services. In Example 2, the client uses one of 
those service handles to obtain the ProtocolDescriptorList attribute for that 
printing service. The transaction illustrates: 

1 SDP client to SDP server: SDP_ServiceAttributeRequest, presenting the 
previously obtained service handle (the one denoted as qqqqqqqq) and 
specifying the ProtocolDescriptorList attribute ID (AttributelD 0x0004) as the 
only attribute requested (other attributes could be retrieved in the same 
transaction if desired). The TransactionID is illustrated as uuuu to distin- 
guish it from the TransactionID of Example 1 . 

2 SDP server to SDP client: SDP_ServiceAttributeResponse, returning the 
ProtocolDescriptorList for the specified printing service. This protocol stack 
is assumed to be ( (L2CAP), (RFCOMM. 2), (PostscriptStream) ). The Proto- 
colDescriptorList is a data element sequence in which each element is, in 
turn a data element sequence whose first element is a UUID representing 
the protocol, and whose subsequent elements are protocol-specific parame- 
ters In this example, one such parameter is included for the RFCOMM pro- 
tocol an 8-bit value indicating RFCOMM server channel 2. The Transaction 
ID is the same value as supplied by the SDP client in the corresponding 
request (uuuu). The Attributes returned are illustrated as a data element 
sequence where the protocol descriptors are 32-bit UUIDs and the 
RFCOMM server channel is a data element with an 8-bit value of 2. 



/* Sent from SDP Client to SDP server */ 
SDP_ServiceAttributeRequest [17] { 

PDUID[1] { 
0x04 

TransactionID t2] { 
Oxuuuu 

} 

ParameterLength [21 { 
OxOOOC 

ServiceRecordHandle [4] { 
Oxqqqqqqqq 

MaximumAttributeByteCount [2] { 
0x0080 

} 

AttributelDList [5] { 

DataElementSequence [5] { 
ObOOllO OblOl 0x03 
AttributelD [3] { 

ObOOOOl ObOOl 0x0004 

) 

} 
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Contimiat ions tat e [1] { 

/* no continuation state */ 
0x00 

} 

} 

/* Sent from SDP server to SDP client */ 
SDP_ServiceAttributeResponse [36] { 

PDUIDtll { 
0x05 

} 

TransactionID (2] ( 
Oxuuuu 

} 

ParameterLength [2] { 
0x0021 

AttributeListByteCount [21 { 
OxOOlE 

} 

AttributeList [30] { 

DataElementSequence [30] { 
ObOOllO OblOl OxlC 
Attribute [28] { 
AttributelD [3] { 

ObOOOOl ObOOl 0x0004 

} 

AttributeValue [25] { 

/* ProtocolDescriptorList */ 
DataElementSequence [25] { 
ObOOllO OblOl 0x17 
/+ L2CAP protocol descriptor */ 
DataElementSequence [7] { 
ObOOllO OblOl 0x05 
UUID[5] { 

/* L2CAP Protocol UUID */ 
ObOOOll ObOlO <32-bit L2CAP UUID> 

} 

/* RFCOMM protocol descriptor */ 
DataElementSequence [9] { 
ObOOllO OblOl 0x07 
UUID[5] { 

/* RFCOMM Protocol UUID */ 
ObOOOll ObOlO <32-bit RFCOMM UUID> 

} 

/* parameter for server 2 */ 
Uint8[2] { 

ObOOOOl ObOOO 0x02 

} 

/* PostscriptStream protocol descriptor */ 
DataElementSequence [7] { 

ObOOllO OblOl 0x05 

UUID [5] { 

/* PostscriptStream Protocol UUID */ 

ObOOOll ObOlO <32-bit PostscriptStream UUID> 
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} 

} 

} 

} 

} 

} 

} 

ContinuationState [1] { 

/* no continuation state */ 
0x00 

} 

} 
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B.3. SDP Example 3 - ServiceSearchAttributeTransaction 

The third example is a form of service browsing, although it is not 9 e " enc 
browsing in that it does not make use of SDP browse groups. Instead, an SDP 
client is searching for available Synchronization services that can be presented 
to the user for selection. The SDP client does not specify a particular type of 
synchronization service. In the example, the SDP server has three available 
synchronization services: an address book synchronization service and a cal- 
endar synchronization service (both from the same provider), and a second 
calendar synchronization service from a different provider. The SDP client is 
retrieving the same attributes for each of these services; namely, the data for- 
mats supported for the synchronization service (vCard, vCal, ICal, etc.) and 
those attributes that are relevant for presenting information to the user about 
the services. Also assume that the maximum size of a response is 400 bytes. 
Since the result is larger than this, the SDP client will repeat the request sup- 
plying a continuation state parameter to retrieve the remainder of the response. 
The transaction illustrates: 

1 SDP client to SDP server: SDP_ServiceSearchAttributeRequest, specifying 
' the qeneric Synch ronisationServiceClassID (represented as a data element 
whose 32-bit UUID value is sss . . . sss) as the only element of the Service- 
SearchPattern. The SynchronisationServiceClassID is assumed to be a 32- 
bit UUID The requested attributes are the ServiceRecordHandle (attribute 
ID 0x0000), ServiceClasslDList (attribute ID 0x0001), IconURL (attribute ID 
OxOOOC) ServiceName (attribute ID 0x0100), ServiceDescription (attribute 
ID 0x0101) and ProviderName (attributed 0x0102) attributes; as well as 
the service-specific SupportedDataStores (AttributelD 0x0301 ). Since the 
first two attribute IDs (0x0000 and 0x0001) and three other attribute 
IDs(0x0100, 0x0101, and 0x0102 are consecutive, they are specified as 
attribute ranges. The Transaction! D is illustrated as ww to distinguish it 
from the TransactionlDs of the other Examples. 

Note that values in the service record's primary language are requested^ 
the text attributes (ServiceName, ServiceDescription and ProviderName) so 
that absolute attribute IDs may be used, rather than adding offsets to a base 
obtained from the LanguageBaseAttributelDList attribute. 
2 SDP server to SDP client: SDP.ServiceSearchAttributeResponse, returning 
" the specified attributes for each of the three synchronization services. In the 
example each ServiceClasslDList is assumed to contain a single element, 
the generic SynchronisationServiceClassID (a 32-bit UUID represented as 
sss sss) Each of the other attributes contain illustrative data in the exam- 
ple (the strings have illustrative text; the icon URLs are illustrative, for each 
of the respective three synchronization services; and the SupportedDataS- 
tore attribute is represented as an unsigned 8-bit integer where 0x01 = 
vCard2.1 , 0x02 = vCard3.0, 0x03 = vCah .0 and 0x04 = iCal). Note that one 
of the service records (the third for which data is returned) has no Service- 
Description attribute. The attributes are returned as a data element 
sequence, where each element is in turn a data element sequence repre- 
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senting a list of attributes. Within each attribute list, the ServiceClasslDList is 
a data element sequence while the remaining attributes are single data ele- 
ments The Transaction ID is the same value as supplied by the SDP client 
in the corresponding request (cbgjgsgj). Since the entire result cannot be 
returned in a single response, a non-null continuation state is returned in this 
f irst response. 

Note that the total length of the initial data element sequence (487 in the 
example) is indicated in the first response, even though only a portion of this 
data element sequence (368 bytes in the example, as indicated in the 
AttributeLists byte count) is returned in the first response. The remainder of 
this data element sequence is returned in the second response (without an 
additional data element header). 

3 SDP client to SDP server: SDP.ServiceSearchAttributeRequest, with the 
' same parameters as in step 1, except that the continuation state received 

from the server in step 2 is included as a request parameter. The Transac- 
tions is changed to oxococo to distinguish it from previous request. 

4 SDP server to SDP client: SDP.ServiceSearchAttributeResponse, with the 

' remainder of the result computed in step 2 above. Since all of the remaining 
result fits in this second response, a null continuation state is included. 

/* Part 1 -- Sent from SDP Client to SDP server */ 
SdpSDP_ServiceSearchAttributeRequest [33] { 

PDDID [1] { 
0x06 

} 

Transact ionID [2] { 
Oxww 

ParameterLength[2] { 
0x00 IB 

ServiceSearchPattern [7] { 

DataElementSequence[7] { 

ObOOllO OblOl 0x05 

UUID [5] { 

/* SynchronisationServiceClassID */ 

ObOOOll ObOlO Oxssssssss 

} 

) 

MaximumAttributeByteCount [2] { 
0x0190 

} 

AttributelDList [18] { 

DataElementSequence [18] { 
ObOOllO OblOl 0x10 
AttributelDRange [5] { 

ObOOOOl ObOlO 0x00000001 

} 

AttributeID[3] { 

ObOOOOl ObOOl OxOOOC 
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AttributelDRange [5] { 

ObOOOOl ObOlO 0x01000102 

} 

AttributeID[3] { 

ObOOOOl ObOOl 0x0301 



ContinuationState [1] { 

/* no continuation state */ 
0x00 



/* Part 2 Sent from SDP server to SDP client */ 
SdpSDP_ServiceSearchAttributeResponse [384] { 
PDUIDI1] { 
0x07 



Oxww 

ParameterLength [2] { 
0X017B 

} 

AttributeListByteCount [2] { 
0x0170 

} 

AttributeLists [368] { 

Da taElement Sequence [487] { 
ObOOllO ObllO 0x01E4 
DataElementSequence [178] { 
ObOOllO OblOl OxBO 
Attribute [8] { 

AttributeID[3] { 

ObOOOOl ObOOl 0x0000 



AttributeValue [5] { 

/* service record handle */ 
ObOOOOl ObOlO Oxhhhhhhhh 



} 

} 

Attribute [10] { 
AttributeID[3] { 

ObOOOOl ObOOl 0x0001 

} 

AttributeValue [7] { 



DataElementSequence [7] { 
ObOOllO OblOl 0x05 
UUID[5] { 

/* SynchronisationServiceClassID */ 
ObOOOll ObOlO Oxssssssss 



} 

} 

} 

} 

Attribute [35] { 



TransactionID[2] { 
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AttributeID(3] { 

ObOOOOl ObOOl OxOOOC 

AttributeValue [32] { 

/* IconURL; '*' replaced by client application */ 

ObOlOOO OblOl OxlE 

" ht t p : / / Synchroni sa t ion/ i cons / * M 

} 

} 

Attribute [22] { 
AttributelD[3] { 

ObOOOOl ObOOl 0x0100 

AttributeValue [19] { 
/* service name */ 
ObOOlOO OblOl 0x11 
"Address Book Sync" 

} 

} 

Attribute [5 9] { 
AttributeID[3] { 

ObOOOOl ObOOl 0x0101 

} 

AttributeValue [56] { 

/* service description */ 
ObOOlOO OblOl 0x36 
"Synchronisation Service for" 
" vCard Address Book Entries" 

} 

} 

Attribute [3 7] { 
AttributeID[3] { 

ObOOOOl ObOOl 0x0102 

} 

AttributeValue [34] { 

/* service provider */ 
ObOOlOO OblOl 0x20 

"Synchronisation Specialists Inc." 

} 

} 

Attribute [5] { 

AttributeID[3] { 

ObOOOOl ObOOl 0x0301 

AttributeValue [2] { 

/* Supported Data Store 'phonebook' */ 
ObOOOOl ObOOO 0x01 

} 

} 

} 

DataElementSequence [175] { 
ObOOllO OblOl OxAD 
Attribute [8] { 
AttributeID(3] { 

ObOOOOl ObOOl 0x0000 

AttributeValue [5] { 
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/* service record handle */ 
ObOOOOl ObOlO 0 xmmmmmmmm 

} 

} 

Attribute [10] { 
AttributeID[3] { 

ObOOOOl ObOOl 0x0001 

} 

AttributeValue [7] { 
DataElement Sequence [7] { 
ObOOllO OblOl 0x05 
UUIDI5] { 

/* SynchronisationServiceClassID */ 
ObOOOll ObOlO Oxssssssss 

} 

} 

} 

Attribute [3 5] { 
AttributeID[3] { 

ObOOOOl ObOOl OxOOOC 

} 

AttributeValue [32] { 

/* IconURL; '*' replaced by client application */ 

ObOlOOO OblOl OxlE 

'» ht tp : / /Synchronic at ion/ icons/ * n 

} 

} 

Attribute [21] { 
AttributeID[3] { 

ObOOOOl ObOOl 0x0100 

} 

AttributeValue [18] { 
/* service name */ 
ObOOlOO OblOl 0x10 
"Appointment Sync" 

} 

} 

Attribute [57] { 
AttributeID[3] { 

ObOOOOl ObOOl 0x0101 

} 

AttributeValue [54] { 

/* service description */ 
ObOOlOO OblOl 0x34 
"Synchronisation Service for" 
" vCal Appointment Entries" 

) 

} 

Attribute [37] { 
AttributeID[3] { 

ObOOOOl ObOOl 0x0102 

AttributeValue [34] { 

/* service provider */ 
ObOOlOO OblOl 0x20 

"Synchronisation Specialists Inc." 
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} 

} 

Attribute [5] { 

AttributeID(3] { 

ObOOOOl ObOOl 0x0301 

} 

AttributeValue [2] { 

/* Supported Data Store 'calendar' */ 
ObOOOOl ObOOO 0x03 

} 

} 

/* } Data element sequence of attribute lists */ 
/* is not completed in this PDU. */ 

ContinuationState [9] { 

/* 8 bytes of continuation state */ 
0x08 Oxzzzzzzzzzzzzzzzz 

} 

} 

/* Part 3 Sent from SDP Client to SDP server */ 
SdpSDP_ServiceSearchAttributeRequest [41] { 

PDUIDC1] { 
0x06 

TransactionID [2] { 
Oxwwww 

Parameter Length [2] { 
0x0024 

} 

ServiceSearchPattem [7] { 
DataElement Sequence [7] { 
ObOOllO OblOl 0x05 
UUIDC5] { 

/* SynchronisationServiceClassID */ 
ObOOOll ObOlO Oxssssssss 

} 

} 

MaximumAttributeByteCount [2] { 
0x0180 

} 

AttributelDList [18] { 
DataElementSequence [183 { 
ObOOllO OblOl 0x10 
Attribute IDRange [5] { 

ObOOOOl ObOlO 0x00000001 

AttributeID[3] { 

ObOOOOl ObOOl OxOOOC 

} 

AttributelDRange [5] [ 

ObOOOOl ObOlO 0x01000102 

AttributeID[3] { 
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ObOOOOl ObOOl 0x0301 

} 

} 

ContinuationState [9] { 

/* same 8 bytes of continuation state */ 
/* received in part 2 */ 

0x08 0XZZZZ2ZZZZZ2ZZZZZ 

} 

} 

Part 4 Sent from SDP server to SDP client 

SdpSDP_ServiceSearchAttributeResponse [115] { 

PDUID[1] { 
0x07 

TransactionID [2] { 
Oxwwww 

Par ameterLengt h [ 2 ] { 
OX006E 

AttributeListByteCount [2] { 
0xOO6B 

AttributeLists[107] { 

/* Continuing the data element sequence of / 
/* attribute lists begun in Part 2. */ 
DataElementSequence [107] { 
ObOOllO OblOl 0x69 
Attribute [8] { 

AttributelDUJ { 

ObOOOOl ObOOl 0x0000 

AttributeValue [5] { 

/* service record handle */ 
ObOOOOl ObOlO Oxffffffff 

} 

} 

Attribute [10] { 
AttributeID[3] { 

ObOOOOl ObOOl 0x0001 

AttributeValue [7] { 

DataElementSequence [7] ( 
ObOOllO OblOl 0x05 

UUID[5] t __ 
/* synchronisationServiceClassID */ 

ObOOOll ObOlO Oxssssssss 

} 

} 

} 

} 

Attribute [3 5] I 
AttributeID[3] { 

ObOOOOl ObOOl 0X00OC 
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AttributeValue [32] { 

/* IconURL; '*' replaced by client application */ 

ObOlOOO OblOl OxlE 

"http : / / DevManuf acturer / icons / * " 

} 

Attribute [183 { 
AttributeID[3] { 

ObOOOOl ObOOl 0x0100 

AttributeValue [15] { 
/* service name */ 
ObOOlOO OblOl OxOD 
"Calendar Sync" 

} 

Attribute [29] { 
AttributeID[3] { 

ObOOOOl ObOOl 0x0102 

1 

AttributeValue [26] { 

/* service provider */ 
ObOOlOO OblOl 0x18 
"Device Manufacturer Inc." 

} 

} 

Attribute [5] { 

AttributelD [3] { 

ObOOOOl ObOOl 0x0301 

AttributeValue [2] { 

/* Supported Data Store 'calendar' */ 
ObOOOOl ObOOO 0x03 

} 

} 

/* This completes the data element sequence */ 
/* of attribute lists begun in Part 2. 

} 

ContinuationState [1] { 

/* no continuation state */ 
0x00 

} 

} 
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